Legacy applications and changing environments can make it difficult to adapt interoperating programs to new versions and environments. In some cases, a legacy program may depend on a first protocol while a support system may move to a second protocol. For example, a legacy program may be a website management system and the support system may be a virtual machine management system. The first protocol may have drawbacks, such as dependence on an outdated and/or easily compromised protocol. For example, it may be discovered that a legacy application uses HTTP basic authentication and HTTP POST actions where credentials are sent in plaintext and easily intercepted. A support system for the application may move to an application programming interface (API) over transport layer security (TLS) for greater security. In some cases, a legacy request may be directly translated by a trusted entity. For example, an old website management system may be configured to place requests for virtual machine starting and stopping through a first version of an API that may be directly translated to a second version of an API by a trusted service provider.
However, there may be problems with direct translation of a protocol by a trusted entity. For example, traditional security models for request delegation may include a highly privileged trust relationship between the services. This trust may undermine the intent for the services to be independent. In another example, not all protocols may be directly translated. There may not be a direct mapping from a first protocol to a second protocol. While various techniques have been employed to effectively adapt interoperating programs to new program versions and environments, due to the complexity of the tasks, the employed techniques are of varied success.